The present invention relates to the processing of data in a telecommunications network.
It relates more particularly to the sending of notifications from a network operator to service providers hosting and managing services in the network, particularly notifications concerning the consumption of resources (bandwidth) by users of such service providers.
“Service Provider” is understood to mean any entity able to provide any kind of service involving data streams exchanged on the telecommunications network. The data stream may be transported over the network between a user terminal and a dedicated server of the service provider, or may be transported between two user terminals, for example when the data streams are WebRTC (“Web Real Time Communication”). In the latter case, the service provider allows the two users to establish a connection and then exchange WebRTC data streams directly. Although the invention is described specifically in connection with WebRTC streams, it applies to any type of data stream.
The WebRTC protocol is a protocol for establishing direct peer-to-peer (P2P) communications between Internet browsers installed on two user terminals. For example, it allows P2P videoconferencing and media exchange, P2P file sharing, or VoIP (“Voice over Internet Protocol”).
The WebRTC protocol offers three programming interfaces (APIs):                the MediaStream (MS) API for accessing a user's data streams (video via a webcam, audio via the microphone, etc.);        the PeerConnection (PC) API for establishing P2P communication between two users' browsers and for exchanging conversational data streams (audio and video that can be transported with the SRTP/UDP protocol suite);        the DataChannel (DC) API for exchanging raw data streams (text or binary data that can be transported with the SCTP/DTLS/UDP protocol suite).        
The use of WebRTC PC and DC APIs generates P2P data streams that typically use the UDP (“User Datagram Protocol”) transport protocol, but sometimes the TCP (“Transmission Control Protocol”) transport protocol. “Data stream” is understood to mean a set of data packets transmitted unidirectionally between two entities (two P2P user terminals or between a user terminal and a server). A data stream is characterized by a source IP address (the sender of the stream), a source port number, a destination IP address (the recipient), a destination port number, and a transport protocol.
A service provider often uses the maximum possible bandwidth without taking into account the bandwidth requirements of other service providers on the network.
In the WebRTC context for example, the browser of a user terminal does not take into account the bitrate used; although it may provide statistical information (bits sent, bits received, timestamp data) that enable measuring the bitrate used by a WebRTC API, this does not allow controlling the bitrate.
Some WebRTC software implementations offer congestion prevention mechanisms defined by the RMCAT (“RTP Media Congestion Avoidance Techniques”) working group for the SRTP (“Secure Real-time Transport Protocol”) protocol for the PC API, and mechanisms inherent to the SCTP (“Stream Control Transmission Protocol”) protocol for the DC API.
However, these mechanisms are intra-stream mechanisms, as they only prevent the data stream from causing local congestion on the telecommunications network. These software implementations do not provide for cross-stream mechanisms.
However, some data streams can consume many more bits per second than other data streams, transported by the TCP protocol for example, which impacts the available bandwidth for TCP data streams such as Youtube™ or Facebook™ data streams. In particular, a WebRTC data stream may consume so many resources that it can impact other WebRTC data streams.
Thus a situation of congestion or pre-congestion may occur in the telecommunications network, and a data stream can monopolize a significant portion of the available bandwidth without the service provider in charge of the data stream being aware of the congestion situation. The service provider thus cannot implement an appropriate policy for adjusting the bandwidth allocation for some of its users, and the congestion situation is not resolved.
The work of the IETF (“Internet Engineering Task Force”) on CONEX (“CONgestion EXposure”) provides a technical solution where network equipment can indicate to the service provider, and to other network elements along the path of the data stream, the state of congestion in the network. For this purpose, a congestion flag is set at the IP layer. The flag is detectable by any entity through which the data stream travels.
The CONEX solution therefore makes the congestion information public, which is undesirable for confidentiality reasons for some service providers. In addition, it is only compatible with the TCP transport protocol and does not handle data streams transported by UDP. Use of the UDP transport protocol is increasing because of its speed, however. The control of congestion by existing solutions is therefore not possible for controlling data streams transported by UDP.
In general, there is a need to control the bandwidth consumed by data streams transported by a certain protocol, while maintaining a high level of confidentiality for the service providers in charge of the data streams.